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EXECUTIVE  SUMMARY 


This  paper  explored  the  process  for  development,  implementation  and  testing  of  an 
Electronic  Security  Solution.  One  way  to  measure  the  effectiveness  of  a  facilities 
protection  effort  is  to  have  clearly  defined  end  users’  needs  and  successfully  test  the 
system  against  those  needs.  The  solution  is  only  effective  when  you  meet  these  needs.  An 
Electronic  Security  System  (ESS)  is  the  combination  of  the  individual  electronic  security 
components  working  as  a  single  entity  within  a  larger  security  plan.  Some  of  the  common 
electronic  ESS  components  are  video  surveillance  cameras,  identification  (ID)  card 
readers,  motion  detectors  with  many  other  sensors  and  related  software. 

There  are  significant  costs  associated  with  security  solutions.  The  world  security 
services  marketplace  is  expected  to  grow  past  the  $218  billion  mark  in  U.S.  dollars  by 
2014  (The  Freedonia  Group,  2011,  p.  4).  By  that  same  year,  the  electronic  security 
equipment  marketplace  world  demand  will  exceed  $99  billion  U.S.  dollars  (The 
Freedonia  Group,  2010,  p.  4).  According  to  Keating  (2010),  by  2017,  “Governments  and 
institutions  will  spend  $3.8  billion  annually  on  security  systems”  (p.  1).  In  2002  the  local 
law  enforcement  community  in  the  United  States  responded  to  36  million  calls  resulting 
from  electronic  security  systems  with  the  false  alarms  costing  an  estimated  $1.8  Billion 
(Sampson,  2001,  p.  7).  That  translates  into  the  equivalency  of  35,000  full-time  police 
officers  nationwide  doing  nothing  but  responding  to  false  alarms  from  electronic  security 
systems  (Sampson,  201 1,  p.  8). 

There  is  no  literature  on  ESS  requirements  as  an  engineering  activity  like  those 
found  in  the  software  or  other  industries.  Most  security  development  and  implementation 
processes  begin  with  a  variation  of  a  survey  or  risk  assessment  and  go  directly  into 
defining  a  set  of  solutions  as  the  end  user  requirements.  A  security  expert  must  assume 
what  the  end  users  security  needs  are  within  these  processes  or  surveys.  A  design  is  then 
completed  based  on  this  expert  opinion.  The  system  is  tested  and  accepted  validating  the 
design  was  installed  properly.  This  results  in  the  installed  perceived  solution  being 
validated  as  effective  and  not  the  actual  end  user  security  needs  being  solved. 


The  Requirements,  Alternative,  Design,  Implementation,  Testing  and 
Commissioning  (RADITC)  process  was  developed  based  on  a  common  industry  practice 
and  the  Integrated  Defense  Acquisition,  Technology  and  Logistic  Life  Cycle 
Management  System.  These  are  requirements  development,  analysis  of  alternatives, 
design,  implementation,  test  and  ending  with  the  commission  of  the  final  solution.  This 
could  be  used  by  anyone  who  has  basic  management  skills  but  may  require  an  additional 
detailed  support  package  for  some  of  the  steps  provided  by  different  certified 
professionals.  All  of  the  steps  can  be  modified  for  each  specific  problem  set  or  issues,  but 
the  steps  themselves  and  the  order  they  fall  in  are  recommended  for  a  successful 
implementation  of  this  method.  The  method  results  in  a  tested  system  based  on  end-user’s 
needs.  Further  validation  or  testing  of  the  needs  during  the  systems  useful  life  can  ensure 
the  system  maintains  its  effectiveness  over  time. 


I.  INTRODUCTION 


We  spend  our  time  searching  for  security  and  hate  it  when  we  get  it. 

-John  Steinbeck 

An  Electronic  Security  System  (ESS)  is  the  combination  of  the  individual 
electronic  security  components  in  its  entirety  working  as  a  single  entity  within  a  larger 
security  plan.  Some  of  the  common  electronic  components  of  an  ESS  are  video 
surveillance  cameras,  identification  (ID)  card  and  biometric  readers,  motion  detectors 
with  many  other  sensors  and  related  software.  Electronic  security  systems  serve  to  detect 
and  delay  intruders  to  increase  the  likelihood  that  end  users  will  have  enough  time  to 
assess  the  threats  and  deploy  responders  in  time  to  thwart  an  attack  if  needed  (Sandia 
National  Laboratories,  2012). 

The  English  inventor  Tildesley  invented  the  first  modern  electronic  security 
device  in  the  early  eighteenth  century  (Seungmug,  2008,  p.  26).  Since  then,  practitioners 
and  professionals  of  all  varieties  have  been  looking  for  ways  to  use  these  new  tools  to 
solve  security  and  life  safety  issues.  Some  of  them  have  been  looking  for  a  problem  for 
the  newest  and  greatest  electronic  security  solution  to  solve  while  others  are  looking  to 
install  an  electronic  solution  because  they  believe  not  having  one  is  the  problem.  Few  of 
these  experts  ask  exactly  what  does  the  end  user  need  solved  and  how  will  it  interact  with 
the  daily  activities  of  the  entire  entity  requiring  a  solution. 

There  is  a  limited  amount  of  research  on  Electronic  Security  Systems,  and  it  is 
unclear  if  the  systems  widely  used  today  are  providing  a  value  compared  to  the  cost  or 
even  increase  security.  A  large  amount  of  money  is  being  expended  on  electronic  security 
systems  and  false  alarms  or  system  malfunctions  are  a  clear  problem.  This  thesis  focused 
on  the  process  used  in  developing  the  initial  needs  and  the  solution  through  testing  of 
those  needs  within  the  final  solution. 

Many  of  the  practitioners  in  Electronic  Security  are  self-certified  experts  based  on 
years  of  performing  the  art  of  security  and  not  based  on  any  formal  higher  degree  in 
security,  certification  or  applications  of  scientific  methods  that  result  in  a  replicable 
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solution.  As  in  many  art  forms,  the  expert  is  always  right  and  few  times  do  different 
experts  with  different  background  end  up  with  the  similar  solution  to  the  same  problem. 

A.  THE  PROBLEM 

Shortly  after  September  11,  2001,  most  of  the  companies  listed  in  the  New  York 
Stock  Exchange  lost  value  and  some  industries  lost  a  significant  percentage  of  business 
along  with  the  downturn  in  value.  However,  companies  like  L-3  Communications 
Holdings  Inc.  (NYSE:  LLL),  URS  Corp  (NYSE:  URS),  Siemens  (NYSE:  SI)  and 
Lockheed  Martin  Corp  (NYSE:  LMT)  all  made  significant  gains  within  the  weeks  and 
months  after  the  attack  (Google,  2012).  These  companies  were  well  suited  for  the  new 
burgeoning  age  of  spending  on  electronic  security  systems.  The  world  security  services 
marketplace  is  expected  to  grow  past  the  $218  billion  mark  in  U.S.  dollars  by  2014  (The 
Freedonia  Group,  2011,  p.  4).  By  that  same  year,  the  electronic  security  equipment 
marketplace  world  demand  will  exceed  $99  billion  U.S.  dollars  (The  Freedonia  Group, 
2010,  p.  4).  According  to  Keating  (2010),  by  2017,  “Governments  and  institutions  will 
spend  $3.8  billion  annually  on  security  systems”.  As  seen  with  the  problems  of  false 
alarms,  the  results  have  not  drastically  improved  compared  with  the  ability  of  the  core 
units  of  these  electronic  systems. 

Often  a  system  will  fail  to  meet  user  expectations,  or  even  basic  needs,  because 
the  supplied  requirements  were  incomplete,  inconsistent,  mistaken,  uninteroperable  or 
simply  unmanageable  (Edwards,  Flanzer,  Terry  &  Landa,  1995,  p.  278).  Many  issues  are 
a  result  of  undocumented  requirements  or  assumptions  on  the  part  of  the  system 
designers  that  lead  to  mistaken,  inconsistent,  ambiguous,  incomplete  or  forgotten 
requirements  (Edwards,  Flanzer,  Terry  &  Landa,  1995,  p.  278).  Many  physical  security 
measures  did  not  meet  the  users  security  needs  because  the  implications  of  what  was 
needed  were  not  fully  thought  through  (Spaight,  2000,  p.  64).  A  good  requirement  should 
provide  the  link  between  the  needs  and  the  procurement  process  and  they  are  easy  to 
consider  in  principle  but  hard  to  develop  in  practice  (Spaight,  2000,  p.  64). 

Many  studies  pointed  out  that  poor  system  design;  implementation,  poor  training 
and  integration  into  daily  activities  are  the  common  causes  for  most  of  the  false  alarms  by 
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electronic  security  systems  (Sampson,  2011,  p.  9).  A  system  based  on  a  solid  set  of 
requirements  that  are  integrated  into  the  facility  or  organizational  operations  should 
overcome  most  of  these  challenges.  This  will  increase  security,  lessen  cost,  strengthen  the 
surrounding  community  and  perform  the  missions  electronic  security  systems  are  created 
to  solve. 

B.  RESEARCH  QUESTIONS 

What  is  a  simple  and  repeatable  systems  engineering  process  that  promotes  an 
effective  electronic  physical  security  system? 

C.  BACKGROUND 

1.  Physical  Security 

Physical  security,  or  more  specifically,  the  use  of  access  controls  where  used  as 
early  as  1000  BC  in  China  where  a  system  was  developed  to  control  access  to  the 
imperial  palace  with  different  types  of  ornate  rings  (Snyder  &  Neil,  1989,  p.  26).  A 
physical  security  system  refers  to  the  protection  of  building  sites  and  equipment  from 
theft,  vandalism,  natural  disaster  and  man-made  catastrophes  (Szuba,  1998  ).  Physical 
security  works  best  when  it  has  more  than  one  layer  of  protection  surrounding  a  target, 
with  each  layer  comprising  of  one  or  more  elements  (Gordon  &  Wyss,  2005,  p.  7).  These 
elements  can  be  physical  structures,  processes,  people  or  ESS. 

Physical  security  measures  aim  to  detect  and  possibly  prevent  a  direct  assault  on 
premises  or  reduce  the  potential  damage  and  injuries  that  can  be  inflicted  should  an 
incident  occur  (Center  for  the  Protection  of  National  Infrastructure,  2012).  Having  a 
security  solution  is  deterrence.  An  overall  physical  security  solution  is  comprised  of  three 
major  functions:  detection,  delay  and  response.  A  key  item  within  detection  is  Electronic 
Security  Systems  (U.S.  Army  Military  Police  School,  2001,  p.  6-1). 

Electronic  security  is  a  key  element  of  physical  security.  The  modem  electronic 
systems  provide  increasingly  better  system  design  possibilities  for  varying  applications, 
improving  with  the  growth  and  expansion  of  the  commercial  electronics  marketplace. 
Recent  technological  advances  provide  advantages  such  as  new  capabilities,  faster 
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detection  and  response  rates,  greater  ease  of  operation  and  lower  error  margins,  thereby 
offering  better  security  (Hoffman,  1989,  p.  74).  These  are  fundamental  ingredients  to  all 
security  efforts.  Without  this  foundation  of  electronic  security  systems,  security  can  be 
considerably  more  difficult,  if  not  impossible,  to  effectively  implement. 

D.  PERFORMANCE  ISSUES 

The  base  technology  of  electronic  security  systems  has  followed  the  growth  of 
communications  and  Internet  Technology.  This  has  revolutionized  security  systems 
design,  detection,  communications  and  monitoring  abilities.  Technology  continues  to 
advance  and  will  continue  to  foster  new  electronic  security  capabilities.  Detection 
equipment  continues  to  develop  as  well,  with  more  sophisticated  devices  and  more 
reliable  sensors  providing  better  sensitivity  and  greater  security  abilities  (DGA  Security 
Systems,  2012,  p.  1).  ESS  leverages  the  growth  in  consumer  electronics,  and  this  increase 
in  capabilities  and  reliability  should  provide  these  same  increases  in  the  electronic 
security  applications  and  results. 

1.  False  Alarm 

False  alarms  are  also  known  as  nuisance  alanns,  false  activation,  false  dispatches, 
false  trigger  or  unknown  alann  activations.  False  alarms  are  those  created  by  electronic 
security  systems  that  do  not  show  an  actual  or  attempted  intrusion  (Ohlhausen  Research  I, 
1993,  p.  6).  False  alarms  comprise  95  to  98  percent  of  all  alarm  calls  to  police  dispatchers 
(Ohlhausen  Research  I,  1993,  p,  6).  In  2002,  the  local  law  enforcement  community  in  the 
United  States  responded  to  36  million  calls  resulting  from  electronic  security  systems 
with  the  false  alarms  costing  an  estimated  $1.8  Billion  (Sampson,  2011,  p.  7).  That 
translates  into  the  equivalency  of  35,000  full-time  police  officers  nationwide  doing 
nothing  but  responding  to  false  alarms  from  electronic  security  systems  (Sampson,  2011, 
p.  8).  Mark  Twain  made  it  clear  in  his  1880  short  story,  The  McWilliamses  and  the 
Burglar  Alarm  that  false  alarms  were  already  well-known  attributes  to  even  the  early 
electronic  security  systems  (Twain,  1922). 
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2.  Engineering  Process 

There  are  many  process,  best  practices,  standards  and  models  that  exist  that 
describe  what  is  commonly  known  as  a  design  or  development  process.  These  all  have 
different  naming  conventions  but  are  basically  a  form  of  an  engineering  process  that 
essentially  details  how  electronic  security  systems  are  designed  and  implemented.  The 
Systems  Engineering  Process,  displayed  in  Figure  1,  is  a  Department  of  Defense 
comprehensive,  iterative  and  recursive  problem  solving  process,  for  transforming  needs 
and  wants  into  a  set  of  system  product  and  process  descriptions.  (DAU,  2001).  This  is  a 
typical  engineering  process.  This  process  typically  begins  by  identifying  the  problem  and 
associated  stakeholders.  The  problem  is  then  properly  defined  and  refined  to  ensure  it 
properly  describes  the  customer’s  needs  (Letoumeau,  2009,  p.  8).  These  are  documented 
in  the  needs  document  and  are  used  as  a  baseline  for  the  entire  design  and  development 
effort  and  become  the  eventual  goal  of  the  system  under  consideration.  In  the  simplest 
tenns,  this  seeks  to  take  what  the  customer  wants  and  needs  through  a  methodical 
process,  eventually  providing  them  with  a  product  or  process  definition  that  meets  the 
needs  at  a  given  level  of  development.  Following  a  predefined  process  to  design, 
development,  implement  and  test  any  major  or  important  system  is  a  common,  if  not 
required,  best  practice. 
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Figure  1.  Systems  Engineering  Process  (From  DAU,  2001) 
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II.  LITERATURE  REVIEW 


Look  for  something ,  find  something  else,  and  realize  that  what  you've 
found  is  more  suited  to  your  needs  than  what  you  thought  you  were 
looking  for.  -Lawrence  Block 

There  are  a  number  of  academic  studies  on  gathering  requirements  in  many 
disciplines.  The  literature  around  system  development  for  electronic  security  is  limited. 
The  review  looked  at  how  the  ESS  industry  defines  what  an  expert  is,  what  requirements 
are  along  with  a  look  at  a  couple  of  different  representative  approaches  to  ESS.  These 
representative  best  practices  are  from  Sandia  National  Labs,  the  United  States 
Departments  of  Homeland  Security  and  Defense  along  with  The  United  Kingdom. 

A.  DEFINING  ELECTRONIC  SECURITY  EXPERTS 

Industrial  security  practitioners  charged  with  government-mandated  protective 
measures  for  military  critical  commercial  infrastructure  created  the  American  Society  of 
Industrial  Security  (ASIS)  in  1955  (Seungmug,  2008,  p.  20).  They  currently  advertise 
over  38,000  members  and  200  local  chapters  worldwide  on  their  website, 
www.asisonline.org.  In  1972,  the  organization  concluded  that  industry  credentials  are 
required,  if  the  vocation  or  art  form  of  security  was  to  become  a  profession  (ASIS,  2012). 
After  approval  of  the  Department  of  Defense,  the  organization  created  the  first  board 
certified  designation  and  certification  program.  The  certifications  from  this  program  were 
awarded  the  Department  of  Homeland  Security  (DHS)  designation  under  Support  Anti- 
Terrorism  by  Fostering  Effective  Technology  (SAFETY)  Act  of  2002  and  are  accredited 
by  the  National  Standards  Institute  (ANSI)  (ASIS,  2012). 

Now  known  just  as  ASIS  International,  this  organization  has  developed  three 
industry  certifications.  The  original  certification  provided  is  the  Certified  Protection 
Professional  (CPP),  and  it  is  for  security  managers.  The  other  two  board  certification 
designations  started  in  2002  (ASIS,  2012).  The  Professional  Certified  Investigator  (PCI) 
is  centered  on  private  investigators.  The  Physical  Security  Professional  (PSP)  board 
certified  designation  is  centered  on  those  in  the  field  who  have  a  primary  responsibility 
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for  physical  security  assessments,  the  application,  design  and  integration  of  physical 
security  systems  and  measures  (ASIS,  2012).  Less  than  nine  thousand  individuals 
worldwide  have  met  the  minimum  requirements  and  have  been  awarded  one  or  more  of 
the  three  board  certification  designations  under  this  program  (ASIS,  2012). 

There  is  a  large  number  of  training  and  certifications  available  from  the 
manufactures  of  the  electronic  security  equipment.  As  an  example,  Pelco  by  Scheider 
Electric  maintains  a  global  training  institute  that  maintains  a  virtual,  along  with  several 
brick  and  mortar  campus  and  provides  an  onsite  technical  training  service  (Pelco,  2012). 
They  are  a  large  traditional  security  camera  manufacturer  and  have  certifications  to 
support  sales  and  design  teams  within  the  entire  product  suite  along  with  individual 
product  specific  certification  and  training  for  the  technical  installation  and  service  teams. 
This  is  typical  for  most  of  the  major  equipment  manufactures.  These  product 
certifications  are  normally  required  by  the  manufactures  for  the  design  and  installation 
companies  to  purchase  equipment,  maintain  the  manufacturers  warranty  and  support 
provided  by  them. 

Many  industry  ESS  experts  present  these  individual  product  certifications  as 
evidence  of  industry  or  market  knowledge.  In  fact,  these  are  limited  to  the  specific 
manufactures  or  individual  product  lines  of  a  single  manufacture.  Too  many  practitioners 
use  this  limited  knowledge  base  and  the  prevailing  processes  that  reply  on  them  to 
develop  sound  security  solutions.  This  easily  results  in  the  solution  meeting  the 
capabilities  of  the  manufacturer’s  features  the  individual  has  been  certified  on  and  not  on 
the  actual  needs  of  the  end  user. 

B.  ELECTRONIC  SECURITY  REQUIREMENTS 

A  significant  amount  of  time  and  work  can  be  saved  if  an  expert  jumped  straight 
to  the  solution  without  defining  the  problem.  If  shortcuts  are  taken,  the  solution  may  not 
be  the  best  choice  among  possible  alternatives  or,  even  worse  we  are  likely  to  find  that 
the  solution  does  not  solve  the  problem,  if  not  make  it  worse  (Cellucci,  2008,  p.  8). 
Gathering  the  correct  requirements  from  all  the  stakeholders  of  a  system  is  so  important 
to  Congress  for  the  Department  of  Defense  (DoD)  that  oversight  councils  and  other 
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related  activities  have  been  codified  in  law  under  10  U.S.C.  181  and  other  acquisition 
related  laws  and  regulations  regarding  the  development  of  new  systems  (Cornell 
University,  2012,  p.  1).  The  DoD  defines  a  requirement  within  the  acquisition  process  as 
a  statement  that  defines  a  product  or  process  operational,  functional,  or  design 
characteristic  or  constraint,  which  is  unambiguous,  testable  or  measurable,  and  necessary 
for  product  or  process  acceptability  (Defense  Acquisition  University,  2008).  Such  a 
requirement  is  considered  a  crucial  component  to  understand  what  a  system  design 
should  accomplish. 

A  common  and  basic  definition  for  a  requirement  is  something  that  is  needed 
(Oxford  University,  2012).  In  practice,  there  are  many  different  types  of  requirements 
that  all  fit  within  this  larger  definition.  It  may  also  be  said  that  a  good  requirement  will  be 
correct,  feasible,  necessary,  prioritized,  unambiguous,  verifiable  and  solution  agnostic 
(Wiegers,  1999).  Some  of  the  more  common  types  are:  functional,  perfonnance  and 
operation  (Project  Performance  International,  2011). 

Functional  requirements  state  what  the  system  should  do  (Halligan,  2012,  p.  2). 
This  captures  the  intended  behavior  of  the  system.  This  behavior  may  be  expressed  as 
services,  tasks  or  functions  the  system  is  required  to  perform  (Malan,  2012,  p.  2).  In  the 
security  context,  functional  requirements  may  state  the  need  to  identify  users  entering  a 
specific  room  or  location. 

Operational  requirements  identify  the  essential  process  or  series  of  actions  to  be 
taken  in  order  to  address  mission  area  deficiencies,  evolving  applications  or  threats, 
emerging  technologies,  or  system  cost  improvements  (Mitre,  2012,  p.  1).  These  typically 
involve  integration  with  the  Concept  of  Operations  (CONOPS)  of  the  location  under 
consideration.  An  example  of  an  operational  requirement  could  state  the  need  to  ensure 
the  proposed  new  system  does  not  increase  labor  force  cost  over  the  current  staffing 
models. 

Performance  requirements  state  how  well  the  system  is  to  complete  the  desired 
task  (Halligan,  2012,  p.  2).  A  performance  requirement  is  generally  defined  in  tenns  of 
degree,  rate,  quantity,  quality,  timeliness,  and  so  on  (Argospress,  2012,  p.  1).  A  good 
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example  could  list  the  accuracy  of  detection  and  in  the  security  context  to  require  the 
security  design  to  ensure  that  the  detection  rate  at  the  entrance  shall  be  100  percent 
accurate. 

A  good  security  requirement  will  include  the  characteristics  of  many  different 
types  of  requirements  but  not  include  the  solution  or  technical  characteristics  of  a 
proposed  solution.  Technical  characteristics  within  the  solution  will  not  facilitate 
technical  and  nontechnical  alternatives  when  looking  for  a  final  resolution.  The  solution 
is  defined  after  all  of  the  requirements  have  been  identified  and  validated  in  any  standard 
system  engineering  or  design  process.  A  solid  security  requirement  for  an  entrance  to  a 
room  may  read:  There  is  a  need  to  identify  all  individuals  entering  this  specific  area  with 
a  100  percent  detection  rate,  accurately  capture  the  date  and  time  of  entrance, 
incorporating  the  current  security  identification  process  used  at  the  facility  while  not 
increasing  current  staffing  levels. 

C.  ASTM 

ASTM  International  (ASTM),  formerly  known  as  the  American  Society  for 
Testing  and  Materials,  is  globally  recognized  for  the  development  and  maintenance  of 
standards.  ASTM  defines  a  specification  as  an  explicit  set  of  requirements 
(www.astm.org).  A  specification  may  contain  a  system  design  and  architecture  but  these 
are  not  interchangeable  documents.  They  typically  categorized  requirements  in  two 
distinct  groups  as  functional  and  nonfunctional.  Functional  requirements  capture  the 
intended  behavior  of  the  system  (Bredemeyer  Consulting,  2012).  This  would  answer  the 
question:  ’’What  should  the  system  do?”  Nonfunctional  requirements  captured  the  criteria 
that  can  be  used  to  judge  the  operation  of  a  system  (Malan,  2001).  This  answer  the 
question:  “What  should  a  system  be?”  Good  clear  sets  of  requirements  are  the  foundation 
of  any  security  system. 

D.  SANDIA  NATIONAL  LABORATORIES 

Sandia  National  Laboratories  is  recognized  as  a  center  of  excellence  related  to 

physical  protection  systems  by  the  Departments  of  Defense  and  Energy.  The  Laboratories 

are  managed  by  the  Sandia  Corporation  and  is  a  wholly  owned  subsidiary  of  Lockheed 
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Martin  Corporation.  They  have  a  mature  process  for  system  design  and  evaluation  that 
was  first  developed  to  protect  nuclear  assets.  This  process  is  used  as  the  reference  for 
many  current  practices  and  concepts  related  to  securing  a  fixed  location  against  physical 
threats.  According  to  Sandia,  “A  physical  protection  system  (PPS)  integrates  people, 
procedures,  and  equipment  for  the  protection  of  assets  or  facilities  against  theft,  sabotage, 
or  other  malevolent  human  attacks”  (Garcia,  2001,  p.  1).  An  Electronic  Security  System 
(ESS)  is  a  significant  component  within  a  physical  protection  system.  Figure  2  shows  the 
Sandia  process  that  follows  a  three-step  process:  Detennine  the  PPS  objectives,  design 
the  PPS  and  analyze  the  design. 
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Figure  2.  Sandia  Process 


Determining  the  PPS  objective  is  the  closest  step  in  the  process  that  determines 
the  requirements  for  the  security  solution.  This  initial  step  requires  the  understanding  of 
the  facility.  This  is  completed  by  a  review  of  the  facility  design,  layout  and  construction 
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along  with  any  other  operations  or  conditions  that  may  affect  the  physical  protection 
system.  The  next  two  steps  described  in  Figure  2  appear  relatively  straightforward. 
Determining  the  threat  and  detennining  what  potential  targets  may  exist  in  the  facility. 
All  these  factors  combined  are  used  to  help  design  the  PPS.  There  is  no  step  in  this 
process  to  specifically  identify  and  document  requirements.  There  is  an  implied 
assumption  in  many  of  the  associated  writings  that  the  detennined  objectives  process 
provides  the  necessary  requirements  without  specifically  identifying  them  as  such.  This  is 
based  on  the  next  step  of  the  process  being  the  actual  design  of  the  PPS.  Any  design 
process  needs  a  baseline  requirement  of  some  order  to  be  a  relevant  design  or  solution.  At 
no  time  does  the  process  verify  the  system  works  as  required. 

This  process  works  well  for  a  highly  technical  and  capable  security  team  that  is 
highly  trained,  certified  and  working  within  a  controlled  environment.  It  assumes  the 
design  team  can  define  the  end  users  need  and  successfully  incorporate  them  into  the 
systems  objectives  based  on  observations  and  not  interactions  or  actual  input  from  the 
end  users  or  other  stakeholders.  A  possible  solution  to  mitigate  this  could  be  the  addition 
of  something  associated  with  the  generation  of  the  end  users  needs  that  would  be  the 
foundation  of  the  PPS  objectives  along  with  other  security  related  activities.  The  needs 
identification  step  is  not  defined  and  no  artifacts  are  provided  that  clearly  delineates  the 
system’s  ultimate  goals.  The  process  goes  right  from  gathering  generic  background  and 
location  infonnation  into  system  design  with  no  ability  to  determine  success  or  whether 
actual  needs  are  met  and  incorporated  into  the  facilities  daily  operations. 

E.  THE  DEPARTMENT  OF  HOMELAND  SECURITY  (DHS) 

The  United  States  Department  of  Homeland  Security  has  several  activities  that  are 
relevant  to  a  methodology  for  determining  and  validating  requirements.  The  U.S. 
Department  of  Homeland  Security  (DHS)  established  the  System  Assessment  and 
Validation  for  Emergency  Responders  (SAVER)  Program  to  assist  emergency  responders 
making  procurement  decisions.  Located  within  the  Science  and  Technology  (S&T) 
Directorate  of  DHS,  the  SAVER  Program  conducts  objective  assessments  and  validations 
of  commercial  equipment  and  systems  and  provides  those  results  along  with  other 
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relevant  equipment  information  to  the  emergency  response  community  in  an 
operationally  useful  form  (U.S.  Department  of  Homeland  Security,  2012,  p.  1).  SAVER 
Reprints  are  reports  produced  by  the  Department  of  Homeland  Security  and  can  be  found 
at  https://www.rkb.us/saver/. 

One  of  the  SAVER  reports  titled  CCTV  Technology  Handbook  has  a  chapter  on 
system  design.  The  report  uses  terms  like  functional  and  operational  requirements 
(SPAWAR,  2006).  “Once  the  surveillance  or  access  control  functional  requirements  are 
identified,  the  operational  requirements  must  be  analyzed  in  detail  to  define  what 
information  the  system  will  be  expected  to  provide  under  the  existing  operating 
conditions  (SPAWAR,  2006,  p.  5).”  Although  these  terms  are  used  throughout  the 
document,  they  are  not  defined,  described  or  used  in  a  means  that  allows  the  reader  to 
understand  what  they  are  and  how  to  create  them.  These  reports  are  considered  industry 
best  practices  and  include  the  applications  of  some  electronic  security  technology. 

F.  THE  DEPARTMENT  OF  DEFENSE  (DoD) 

The  Department  of  Defense  (DoD)  has  several  documents  related  to  electronic 
security  systems  applications  and  requirements.  These  are  a  compilation  of  the  current 
best  practices  and  mandates  associated  with  electronic  security  systems.  The  largest  both 
in  size  and  use  is  the  FM  3-19.20  Physical  Security  Manual.  This  is  referenced  by  many 
internal  and  external  organizations  and  is  intended  to  be  the  one-stop  physical  security 
source  (U.S.  Army  Military  Police  School,  2001,  p.  vi).  It  has  a  focus  on  an  effective 
partnership  between  engineers  and  physical-security  personnel  (U.S.  Army  Military 
Police  School  2001,  p.  3-1).  They  view  the  separation  of  roles  as  a  good  concept  for  the 
development  of  requirements  and  the  design  of  the  system.  This  is  important  because  is 
distinguishes  that  there  are  different  roles  and  skill  sets  required  between  the 
development  of  requirements  and  the  design  of  a  system.  The  manual  describes  the  Army 
policy  that  the  use  of  standard  preapproved  systems,  if  possible  and  available,  as  the 
preferred  method  (U.S.  Army  Military  Police  School,  2001,  p.  6-1).  This  is  important, 
since  the  preapproved  systems  are  based  on  technical  ability,  not  operational  need.  In 
effect,  they  have  a  predefined  solution  looking  to  fit  all  of  their  electronic  security  needs. 
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The  end  users  of  the  Army  manual  will  find  the  implementations  of  these  systems 
are  based  on  general  requirements  tailored  to  a  site-specific  mission  and  physical  profile 
(U.S.  Army  Military  Police  School  2001,  p.  6-2).  The  detennination  on  what  makes  up  a 
site-specific  mission  and  profile  begins  with  a  site  survey.  For  this  effort,  the  manual 
describes  the  inclusion  of  such  factors  as  terrain,  geography,  climate  and  type  of  assets 
needing  the  security  (U.S.  Army  Military  Police  School,  2001,  p.  6-2).  These  are  clearly 
components  of  the  design  criteria  that  an  engineer  should  take  in  consideration  for  the 
system  design.  These  depend  solely  on  the  skill  set  of  the  practitioner  and  not  the  process 
itself. 

The  United  States  Marine  Corps  Physical  Security  Program  Manual,  MCO 
P5 5 3 0.14  provides  the  guidance  they  use  relating  to  physical  security  and  includes 
electronic  security  systems.  They  view  these  as  consisting  of  sensors  that  signal  the  entry 
or  attempted  entry  into  a  protected  area,  not  the  prevention  of  an  entry  (Headquarters 
United  States  Marine  Corps,  2000,  7-3).  The  manual  detennines  who  is  responsible  for 
the  system  but  not  specifically  how  the  design  and  implementation  shall  be  completed. 
Overall,  this  provides  little  guidance  on  how  the  system  will  be  designed  and  operated 
but  has  a  focus  on  who  is  responsible  for  these  processes. 

G.  UNITED  KINGDOM 

The  United  Kingdom  formed  the  Centre  for  the  Protection  of  National 
Infrastructure  (CPNI)  from  the  merger  of  the  National  Infrastructure  Security  Co¬ 
ordination  Centre  (NISCC)  and  a  part  of  MI5  (the  UK's  Security  Service),  the  National 
Security  Advice  Centre  (NSAC)  on  1  February  2007  (Humberside  Police,  2012).  The 
Centre  enables  national  security  for  the  United  Kingdom  by  providing  security  advice 
and  guidance  (Centre,  2010,  p.  4).  They  support  physical,  personnel  and  cyber  security 
efforts.  The  Centre  advocates  the  production  of  Operational  Requirements,  and  they  are 
within  the  United  Kingdom’s  Security  Policy  Framework  (SPF).  These  requirements  are 
based  on  a  process  that  has  been  successfully  applied  across  the  UK  national 
infrastructure  (Centre,  2012).  They  published  a  guide  titled  Guide  to  Producing 
Operational  Requirements  for  Security  Measures.  This  defined  an  Operational 
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Requirement  as  a  statement  of  need  based  upon  a  thorough  and  systematic  assessment  of 
the  problem  to  be  solved  and  the  hoped  for  solutions  (Centre  2012). 

The  Centre’s  guide  is  designed  to  ensure  the  appropriate  security  measures  are 
used  to  manage  risk  by  the  use  of  an  electronic  security  system  (Centre  for  the  Protection 
of  National  Infrastructure,  2010,  p.  2).  They  describe  how  to  develop  Operational 
Requirements  and  how  they  are  broken  down  into  two  levels.  Level  One  Requirements 
are  based  on  the  overall  security  needs  and  level  two  are  more  at  the  component  level.  In 
basic  terms,  a  Level  One  Requirement  would  be  an  entire  campus  or  facility  area.  A 
Level  Two  Requirement  for  the  same  location  would  be  a  specific  solution  within  that 
higher  Level  One  Requirement.  The  example  used  in  the  guidance  document  for  a  Level 
Two  Requirement  is  a  specific  fence,  video  surveillance  or  access  control.  These  require 
you  to  have  a  complete  understanding  of  the  threats  to  that  particular  campus  or  facility 
prior  to  completing  the  Operational  Requirement  generation  process. 

The  generation  process  is  initiated  when  a  security  problem  has  been  identified, 
and  it  is  understood  why  it  has  occurred.  The  process  end-user  is  asked  six  questions,  and 
if  yes  is  answered  to  one  or  more  of  the  first  five,  then  a  Level  One  Requirement  is 
developed.  These  are: 

Are  the  existing  security  measures  inadequate? 

Are  the  existing  security  measures  excessive? 

Has  the  use  of  the  location  changed? 

Has  the  threat  changed? 

The  current  requirements  are  not  clear? 

If  you  answered  no  to  all  of  the  above  and/or  you  can  state  the  existing  security 
measures  are  considered  to  be  appropriate  and  adequate,  then  no  action  is  required  and 
the  process  ends. 

The  actual  development  of  the  Level  Ones  Requirements  requires  the  input  of 
every  stakeholder.  The  Centre’s  guide  defines  stakeholder  as  anyone  who  has  any  interest 
in  the  locations  security  (Centre  for  the  Protection  of  National  Infrastructure,  2010,  p.  4). 
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Everyone  is  provided  a  prefabricated  checklist  of  questions  design  to  ensure  they  have 
some  level  of  input  into  the  development  of  the  requirements.  They  are  asked  to  describe 
the  location,  assets,  threat,  concerns  or  vulnerabilities,  consequences,  definition  of 
success,  other  constraints  and  possible  solutions.  These  are  all  combined  into  summaries 
that  are  the  Level  One  requirement  for  that  location. 

Level  Two  Operational  Requirements  are  framed  around  eleven  predetermined 
solution  sets.  The  sets  are:  Pedestrian  barrier,  lighting,  video  surveillance,  physical  delay 
measures,  procedures,  information  security,  hostile  vehicle,  perimeter  intrusion,  access 
control,  intrusion  detection  and  mail.  Each  one  of  these  areas  has  their  own  prefabricated 
checklist  for  the  stakeholders  to  complete.  These  checklists  cover  topics  from  areas  of 
concerns,  functions  and  vulnerabilities  to  constraints,  success  criteria  and  maintenance 
issues.  As  in  the  higher-level  Operational  Requirements,  the  summaries  of  all  the 
stakeholders’  surveys  for  each  Level  One  end  up  as  the  final  Level  Two  Operational 
Requirements  for  the  facility 

When  broken  down,  this  process  is  a  little  different  from  the  checklist  concept 
used  by  other  entities  in  the  United  States.  The  UK  requires  the  actors  in  the  process  to  be 
well  versed  in  the  systems  used  and  types  of  applications.  This  becomes  a  problem  when 
they  are  only  versed  in  one  technology,  or  one  manufacturer,  or  have  limited  to  no  prior 
experience  in  the  engineering  of  these  systems.  Some  of  the  benefits  of  this  methodology 
are  that  the  definition  of  success  for  the  Operational  Requirements  is  a  core  component, 
and  that  it  does  not  heavily  rely  on  a  single  individual  for  that  single  point  of  failure. 

H.  SUMMARY 

There  is  a  lack  of  agreement  on  defining  a  requirement  and  the  ways  to  create 
them.  An  extremely  limited  amount  of  relevant  academic  literature  was  found  associated 
with  the  Electronic  Security  marketplace.  There  is  no  fonnal  ESS  field  of  study  on 
requirements  as  an  engineering  activity  like  those  found  in  the  software  industry.  Most 
processes  begin  with  a  variation  of  a  survey,  or  risk  assessment,  and  go  directly  into 
defining  a  set  of  solutions  as  the  end  user  requirements.  There  are  a  small  number  of 
board  certified  experts  actively  working  in  the  ESS  field.  These  experts  must  assume 
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what  the  end  users  security  needs  are  based  on  surveys  or  risk  assessments.  This  results  in 
the  system  being  tested  and  accepted  validating  the  design  based  on  experts’  perceived 
solutions  as  installed  and  not  against  the  actual  end  user’s  security  needs  being  resolved. 
The  federal  government’s  integrated  life  cycle  management  system  is  considered 
complex  for  the  average  federal  user  of  the  system  and  will  not  easily  support  an  activity 
like  an  ESS  solution. 
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III.  METHOD 


The  only  real  security  that  a  man  can  have  in  this  world  is  a  reserve  of 

knowledge,  experience  and  ability.  Henry  Ford 

An  overall  physical  security  solution  is  composed  of  three  major  elements: 
detection,  delay  and  response.  Electronic  Security  Systems  are  the  key  components 
within  the  detection  and  delay  elements.  These  are  normally  integrated  systems 
comprised  of  Closed  Circuit  Television  (CCTV),  intrusion  detection,  access  control  and 
other  electronic  means  of  detecting  access  and  intrusion  within  a  defined  location.  There 
are  five  life  cycle  phases  that  make  up  these  systems  and  all  are  crucial  to  quality.  These 
are  the  development  of  the  requirements,  design,  implementation,  operations  and 
maintenance  of  these  systems. 

This  thesis  developed  a  requirements  process  tailored  for  the  development  and 
testing  of  an  ESS.  The  desired  goal  of  the  analysis  was  to  develop  a  process  that  is 
effective,  easy  to  use  and  repeatable. 

A.  DEVELOPMENT  OF  MODEL 

The  new  requirements  process  was  based  on  two  existing  processes.  The  first  is  a 
commercial  best  practice  as  articulated  by  Thomas  J  Whittle  (Whittle,  1987);  the  second 
is  commonly  known  as  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics 
Life  Cycle  Management  System.  Both  of  these  are  important  foundational  process. 

Thomas  J  Whittle,  PE  shared  a  version  of  this  common  industry  practice  in  his 
April  1987  article  called  security  by  design  in  Security  Management  (Whittle,  1987,  p. 
57).  The  checklist  or  survey  methods  used  by  industry  are  this  methodology  or  a  slightly 
modified  version.  These  are  the  basis  for  many  of  the  commercial  applications  in  use 
today. 

The  Integrated  Defense  Acquisition,  Technology  and  Logistics  Life  Cycle 
Management  System  is  the  DoD  and  DHS  Systems  Acquisition  Process.  This  is  the 
process  these  agencies  follow  when  they  need  to  develop,  purchase  and  maintain 
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everything  from  the  largest  nuclear  aircraft  carrier  to  the  employee  identification  card 
(The  Defense  Acquisition  University,  2009).  This  is  based  on  the  Defense  Acquisition 
Guide  and  is  a  very  complicated  process  to  follow.  Figure  4  is  a  roadmap  of  just  the  key 
activities  within  the  systems  acquisition  process  (The  Defense  Acquisition  University, 
2009).  Both  of  these  are  key  components  in  the  development  of  a  new  process. 

The  new  process  included  steps  to  detennine  the  needs,  develop  a  solution  and 
ensure  the  needs  are  captured  within  the  final  solution.  My  personal  experience  played  a 
key  role  within  the  development  process  of  this  new  process.  This  experience  includes 
more  than  twenty-seven  years  within  the  defense  and  security  field.  Within  those  years,  I 
have  held  executive,  program  management  and  project  management  and  team  leadership 
positions.  I  have  successfully  developed  and  led  security-related  assessments,  designs, 
processes  and  teams  in  both  the  government  and  large  industry  applications.  I  have 
served  as  the  primary  decision  maker  on  the  design  and  management  of  many  successful 
large-scale  security  products  and  systems  with  real  world  hands-on  experience.  I 
currently  maintain  a  level  three  certification  in  program  management  within  the 
Department  of  Homeland  Security  and  a  board  certification  as  a  Physical  Security 
Professional. 

B.  DESIRED  CHARACTERISTICS 

Desired  characteristics  for  the  new  process  are:  simple,  repeatable  and  effective. 

1.  Simple 

Simple  is  the  detennination  on  the  ease  in  which  the  process  can  be  implemented 
free  of  secondary  complications.  A  simple  process  will  be  easy  to  use  with  no  specific 
process  based  training  required.  This  will  be  determined  by  the  complexity  and  the  clarity 
of  the  steps  provided.  This  will  have  a  direct  path  between  each  point  in  the  process  when 
displayed  as  a  figure.  Each  step  will  have  a  clear  meaning  and  task.  This  is  a  key 
characteristic,  since  the  average  security  professional  will  not  use  the  process  more  than  a 
couple  of  times  over  an  entire  career,  training  or  consultants  are  costly.  Most  solutions 
are  expensive  and  can  take  years  to  implement  with  at  least  a  five-year  useful  life  after 
implementation. 
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2.  Repeatable 

Repeatable  represents  how  well  a  practitioner  can  apply  this  same  process  in 
multiple  environments.  Process  repeatability  is  the  foundation  for  the  operation  of  a 
successful  process.  In  order  to  measure  the  success  of  a  process,  it  needs  to  be  repeatable. 
Otherwise,  there  is  nothing  consistent  to  measure  and  compare.  To  be  able  to  measure 
process  improvement,  repeatability  is  essential.  So,  repeatability  is  a  critical  factor  in 
continuous  improvement  and  the  ultimate  success  of  a  process.  The  types  of 
environments  a  successful  process  should  work  include  school  campus,  office  buildings 
and  small  manufacturing  facility.  Not  only  should  the  process  be  location  agnostic,  it 
needs  to  be  solution  agnostic.  Having  a  process  that  will  direct  a  solution  into  a  single 
technology  is  not  dynamic  or  repeatable.  The  process  will  fail  if  that  solution  it  provides 
is  not  viable  in  the  environment  the  process  is  being  applied  to.  In  this  context,  a  process 
that  is  location,  technology  and  solution  agnostic  is  considered  to  be  a  repeatable  process. 

3.  Effective 

Effectiveness  refers  to  the  level  of  ability  of  the  method  to  obtain  testable  end  user 
requirements  and  test  the  proposed  electronic  solution  against  them.  The  validation  that  a 
system  is  effective  can  be  done  by  testing  it  against  the  user  needs,  ensuring  it  is 
integrating  into  the  daily  activities  of  the  end  users  to  improve  the  chances  and 
opportunities  it  will  be  successfully  used.  The  process  should  clearly  define  requirements 
by  supporting  the  identification  of  the  end  user  needs.  This  will  facilitate  the  proposed 
solutions  integration  within  daily  activities  to  ensure  the  solution  will  be  utilized.  It  shall 
test  the  solution  directly  against  the  identified  needs. 
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IV.  ALTERNATIVE  DEVELOPMENT 


We  will  bankrupt  ourselves  in  the  vain  search  for  absolute  security. 

Dwight  D.  Eisenhower 

The  method  used  to  take  an  electronic  security  system  from  the  basic  needs  of  an 
end  user  to  an  effective  system  is  important.  It  is  highly  possible  that  a  large  amount  of 
time  and  money  can  be  allocated  to  an  ESS  resulting  in  an  unknown,  little  or  no  real 
amount  of  value.  The  new  requirements  process  was  based  on  two  existing  processes. 
The  first  is  a  commercial  best  practice  as  articulated  by  Thomas  J  Whittle.  This  provides 
a  good  foundation  of  activities.  A  second  more  complex  life  cycle  management  process 
used  by  the  DoD  and  DHS  provided  steps  and  concepts  that  are  missing  from  the 
commercial  best  practices  in  use  today.  This  life  cycle  management  process  is  commonly 
known  as  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System. 

A.  COMMERCIAL  BEST  PRACTICE 

Interviews,  site  surveys  and  other  customer  interactions  are  all  components  of  the 
best  practice  in  industry  to  develop  and  validate  requirements  in  the  electronic  security 
field.  As  shown  in  Ligure  3,  Thomas  J  Whittle,  PE  shared  a  version  of  this  common 
industry  practice  in  his  April  1987  article  called  security  by  design  in  Security 
Management  (Whittle,  1987).  Versions  of  this  are  found  in  many  best  practices  used  by 
security  professionals  and  are  known  as  the  checklist  or  survey  method. 
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Figure  3.  Commercial  Method 


Having  a  clear  understanding  of  the  customers  and  end  users  perspective  are  key 
to  this  method.  What  is  not  shown  in  the  figure  is  the  inclusion  of  customer 
questionnaires  to  help  prepare  for  the  client  interviews.  None  of  the  proposed  interview 
questions  or  missing  steps  to  prepare  for  the  interview  is  publicly  available.  Although  not 
specified  it  could  be  easily  inferred  that  these  are  specific  to  the  expert  conducting  the 
task  along  with  the  nuances  associated  with  the  environment  requiring  some  level  of 
security.  Most  relevant  documentation  heavily  relies  on  the  expertise  and  opinion  of  the 
user  completing  the  development  of  the  requirements  and  design.  This  process  stops  at 
the  beginning  of  the  installation  phase  of  the  project.  At  this  time,  there  are  still  many 
activities  and  events  that  will  determine  how  well  the  system  will  function.  It  is  clear  that 
a  well-designed  system  not  installed  properly  will  not  be  as  effective  as  one  that  is 
installed  properly.  One  of  the  ways  to  verify  the  system  works  as  designed  is  to  test  the 
system  after  installation. 

According  to  Mr.  Whittle  (1987),  a  detailed  site  survey  that  includes 
environmental  and  operational  factors  plays  an  important  role  on  the  design  of  a  system. 
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He  also  advocates  a  regulatory  data  search.  All  of  this  collected  data  should  then  be 
analyzed  or  reduced  to  the  basic  important  facts  to  use  toward  the  design  of  the  system. 
The  process,  or  what  the  results  look  like,  makes  it  difficult  to  understand  this  step  in  the 
process.  At  this  point  in  the  process,  the  development  of  the  requirements  is  completed 
and  forms  what  he  called  generic  requirements.  These  are  used  for  the  systems  design, 
and  the  process  moving  forward  to  include  customer  feedback  and  additional  surveys. 

B.  LIFE  CYCLE  MANAGEMENT  SYSTEM 

The  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System  is  the  DoD  and  DHS  Systems  Acquisition  Process.  This  is  the 
process  these  agencies  follow  when  they  need  to  develop,  purchase  and  maintain 
everything  from  the  largest  nuclear  aircraft  carrier  to  the  employee  identification  card 
(The  Defense  Acquisition  University,  2009).  This  is  based  on  the  Defense  Acquisition 
Guide  and  is  a  very  complicated  process  to  follow.  Figure  4  is  a  roadmap  of  just  the  key 
activities  within  the  systems  acquisition  process  (The  Defense  Acquisition  University, 
2009).  This  is  a  good  graphical  representation  on  how  complex  this  process  is. 
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This  large  and  complex  life  cycle  management  system  can  be  broken  down  into 
five  phases.  The  five  phases  are:  Material  solution  analysis,  technology  development, 
engineering  and  manufacturing,  production  and  deployment  and  operations  and  support. 
This  is  too  complex  to  be  directly  adapted  to  any  ESS  implementation.  This  was 
developed  specifically  for  the  United  States  federal  government  and  the  required 
continual  checks  and  balances  to  ensure  there  is  a  cost  effective  functional  solution  with 
as  little  waste  fraud  and  abuse  as  possible. 

According  to  the  Defense  Acquisition  Guidebook  (DAU,  2009),  the  material 
solution  analysis  phase  is  the  first  phase  a  need  enters  the  acquisition  system.  Prior  to  this 
phase  an  Initial  Capabilities  Document  (ICD)  is  created  that  details  all  the  capabilities 
any  proposed  solution  would  need  to  satisfy  under  the  current  need.  That  means  that  the 
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end  user  has  to  have  a  clear  set  of  requirements  on  what  is  needed  prior  to  even  starting 
the  acquisition  process.  The  requirements  are  developed  by  the  end  user  communicates 
within  the  framework  of  the  ICD  document  template.  The  material  solution  analysis 
phase  will  complete  an  analysis  of  alternatives,  or  determine  what  are  all  the  viable 
solutions  to  meet  the  mission  needs.  At  this  point  in  the  process,  the  government 
determines  the  estimate  cost  of  the  system,  a  development  strategy,  contract  drafts  and 
plans,  system  technical  specifications,  engineering  plans,  support  plans,  cost  manpower 
estimates  and  other  early  supporting  documents  and  decisions. 

The  second  phase  is  the  technology  development  phase.  This  is  the  point  in  the 
process  that  the  performance  parameters  are  determined  that  the  solution  must  meet  based 
on  the  initial  requirements.  Technical  performance  specifications  are  developed  and 
prototypes  of  the  solution  may  also  be  found  within  this  phase.  This  is  the  phase  a  design 
is  completed,  performance  specifications  are  finalized  and  validation  of  the  proposed 
solution  will  meet  all  the  user  needs.  When  this  phase  is  complete,  the  solution  will  be 
ready  for  production. 

The  engineering  and  manufacturing  development  phase  is  next.  This  is  the  step 
that  entails  all  of  the  subprocess  getting  a  solution  from  an  early  prototype  to  early 
production  runs.  This  is  the  phase  the  solution  is  integrated  into  the  regular  field 
operations,  training  and  how  it  will  be  supported  is  determined.  The  integrated  system 
design  is  completed  and  any  prototype  is  updated  to  produce  what  the  baseline  solution 
should  look  like.  An  initial  production  run  may  take  place  to  ensue  the  proposed  solution 
can  be  built  to  meet  all  of  the  user  specifications.  Manpower  affordability  and  life  cycle 
cost  are  all  updated.  The  solution  is  ready  for  full  rate  production  at  this  time. 

The  production  and  deployment  phase  starts  with  a  low  rate  or  initial  production 

run  of  the  solution  and  support  packages  are  built  to  ensure  the  solution  can  be 

successfully  integrated  and  maintained  by  the  end  user  community.  A  full  package  of 

support  and  training  material  for  both  field  operations  and  maintenance  is  delivered  prior 

to  any  solution  being  provided  to  an  end  user.  This  initial  low  rate  production  at  the  start 

of  this  phase  not  only  provides  the  knowledge  on  how  to  efficiently  produce  the  solution 

but  also  provides  the  knowledge  and  solution  components  to  complete  the  training 
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development  and  implementation  for  the  end  users  and  maintenance  personnel.  Training 
prior  to  the  solution  arriving  in  the  hands  of  an  end  user  is  important  to  ensure  they  know 
how  to  safely  use  it  once  it  arrives  but  also  how  to  start  the  initial  preventative  and 
operational  maintenance  on  the  solution  that  will  be  required. 

The  final  phase  is  operations  and  support.  This  is  the  only  time  in  this  life  cycle 
management  system  that  two  phases  may  be  concurrent.  This  starts  as  soon  as  the  first 
production  solution  is  provided  to  the  first  end  user.  This  is  nothing  more  than  the 
operations  and  maintenance  of  the  solution.  It  is  normal  to  have  a  solution  in  the  hands  of 
some  of  the  end  users  and  production  of  the  solution  to  continue  for  a  long  time.  This  is 
continued  unit  the  last  step  of  the  life  cycle  management  system,  solution  disposal. 

C.  ALTERNATIVE  PROCESS  DEVELOPMENT 

Technology  is  in  a  constant  state  of  growth  in  capabilities  and  affordability. 
According  to  Keating,  by  2017,  “Governments  and  institutions  will  spend  $3.8  billion 
annually  on  security  systems”  (Keating,  2010).  By  that  same  year,  the  electronic  security 
equipment  marketplace  world  demand  will  exceed  $99  billion  U.S.  dollars  (The 
Freedonia  Group,  2010,  p.  4).  As  seen  with  the  problems  of  false  alarms,  the  results  have 
not  drastically  improved  compared  with  the  capability  of  the  core  units  of  these  electronic 
systems. 
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Requirements  Development 


/ 


Figure  5.  RADITC  Process 


The  Requirements,  Alternative,  Design,  Implementation,  Testing  and 
Commissioning  (RADITC)  process  was  developed  as  an  alternative  solution  for  the 
Development  and  Validation,  from  Requirements  to  Testing,  of  an  effective  physical 
security  solution.  The  RADITC  Process  in  Figure  5  can  be  broken  down  into  six  major 
activities  or  phases.  The  process  takes  its  name  from  those  six  major  activities.  This  new 
process  is  an  adaptation  of  the  Integrated  Defense  Acquisition,  Technology  and  Logistics 
Life  Cycle  (acquisition)  Management  System  used  by  the  DoD  and  DHS  to  acquire  new 
solutions  along  with  the  commercial  option.  The  six  phases  of  the  alternative  process  fits 
within  the  federal  acquisition  management  system  and  the  commercial  option  provides  a 
good  foundation  for  this  new  process. 
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1.  Requirements 

The  requirements  development  phase  takes  the  beginning  of  the  commercial 
option  and  expands  it  to  include  a  well-defined  result  of  end  user  requirements.  This  uses 
the  same  “rework  as  necessary”  steps  used  in  the  commercial  option  but  expands  the  use 
for  each  phase  of  the  process  to  facilitate  the  validation  of  the  solution  at  multiple  times. 
This  phase  of  the  alternate  solution  provides  the  valid  end  user  requirements.  A  solid  set 
of  end  user  requirements  is  a  key  input  into  the  federal  life  cycle  management  system. 

Maintaining  the  commercial  solutions  approach  in  using  the  location  (site 
surveys),  end  users  inputs  (client  interviews)  and  local  laws  (regulatory  data  research)  are 
important  factors  in  determining  if  any  proposed  solution  can  be  viable  in  the 
environment  it  will  be  used.  This  is  the  foundational  data  for  any  good  set  of 
requirements.  What  is  changed  from  the  commercial  option  is  the  next  step  of  data 
analysis  and  reduction  into  actual  requirements  development.  The  generation  of  a  good 
requirement  is  not  data  analysis  but  the  generation  of  new  data  as  well  defined  needs 
based  on  the  information  gathered  to  this  point. 

The  requirements  development  phase  can  be  split  into  the  data  collection  and  the 
development  itself.  Data  collection  includes  surveys  of  the  location,  environmental  and 
operational  conditions  along  with  stakeholder  interviews  and  knowledge  of  the  regulatory 
requirements.  These  will  provide  all  of  the  data  required  to  understand  what  the  root 
problem  is,  how  a  solution  will  fit  within  the  operations  and  what  conditions  will  impact 
any  proposed  solution.  The  regulatory  data  search  is  a  key  component.  Many  of  the 
security  related  issues  have  relevant  local,  state  and  national  regulations  associated  with 
them  along  with  most  of  the  possible  solutions.  There  is  also  a  significant  amount  of 
domestic  and  international  codes  and  best  practices  that  may  provide  justification  for  or 
unidentified  possible  solutions. 

The  requirements  themselves  should  not  indicate  a  solution.  This  need  to  have  a 
solution  agnostic  approach  to  the  requirements  will  help  ensure  you  have  identified  the 
actual  problems  and  not  just  a  solution  looking  for  a  home.  A  poor  requirement  could  be: 
“have  a  camera  looking  at  an  entrance  to  the  facility.”  The  actual  requirement  may  be  the 
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need  to  recognize  anyone  entering  or  leaving  the  facility  at  any  given  time.  A  guard  with 
or  without  a  mix  of  other  technologies  could  also  solve  that  same  problem  at  a  lower  cost 
or  better  fit  within  the  current  constraints  and  operations  at  that  location.  Limiting  the 
implementation  to  a  specific  solution  as  a  requirement  will  limit  one’s  ability  to  ensure 
the  actual  issue  has  been  solved  and  with  the  best  methodology  within  the  operational 
constraints  of  the  location. 

Once  solid  sets  of  requirements  have  been  created,  they  should  be  vetted  by  all  of 
the  stakeholders.  This  will  help  ensure  that  the  data  gathering  activities  did  not  miss 
anything,  or  there  were  communication  issues  on  what  the  actual  root  problems  are.  This 
gives  the  stakeholders  a  second  chance  with  a  new  perspective  to  ensure  they  have 
identified  all  the  needs  and  have  not  missed  any  or  exaggerated  them  earlier  in  the 
process.  This  leads  to  the  identification  of  possible  solutions. 

2.  Alternative 

The  material  solution  analysis  phase  is  the  first  step  in  the  federal  acquisition 
system.  This  includes  the  analysis  of  alternative  process  that  assesses  the  potential 
material  and  nonmaterial  solutions  in  meeting  the  end  user  needs  (The  Defense 
Acquisition  University,  2009).  This  step  is  not  found  in  the  other  two  processes.  This  was 
added  as  the  next  phase  in  the  alternative  solution  after  the  development  of  the 
requirements.  The  DoD  uses  the  DOTMLFP  problem-solving  construct  to  complete  the 
analysis  of  alternatives.  This  problem-solving  construct  is  further  explored  in  the  last 
chapter  of  this  paper.  As  an  example,  a  good  set  of  alternatives  for  the  requirement  to 
recognize  individuals  entering  a  specific  room  could  be  the  use  of  closed  circuit 
television,  posted  guards  at  the  entrance,  sign-in  sheets,  electronic  access  control  system 
or  local  personnel  always  staffing  the  room  doing  a  visual  check  of  all  identification 
cards. 

Having  the  choice  between  mutually  exclusive  possibilities  will  improve  the 
chances  that  the  solution  provided  from  the  use  of  this  process  will  meet  the  end  users 
needs,  ft  is  also  important  to  recognize  that  even  in  a  process  to  develop  an  ESS  that  a 
policy  change  or  other  nontechnical  solution  may  provide  better  results  for  the  end  users. 
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This  step  will  not  only  provide  alternative  solutions  that  may  be  operationally  or  cost 
effective  but  will  also  validate  the  original  set  of  requirements  developed  by  the  process 
are  as  accurate  as  possible.  A  good  indication  the  requirements  are  not  clear  is  a  lack  of 
nontechnical  or  a  limited  set  of  technical  solutions  developed  by  the  process,  no  matter 
how  cost  or  operationally  effective  they  may  be.  The  best  possible  solutions  or  set  of 
solutions  should  be  presented  for  stakeholder  review  within  the  solution  selection 
process. 


3.  Design 

The  next  phase  in  the  alternative  solution  is  design.  This  includes  the  actual 
design  of  a  solution  and  the  development  of  operational  and  policy  interfaces  to  this 
solution.  This  follows  the  general  concept  in  the  engineering  and  manufacturing 
development  phase  of  the  federal  acquisition  system  that  ensures  the  solution  can  be 
successfully  integrated  into  and  maintained  by  the  end  user  community.  This  is  a  missed 
step  in  all  of  the  existing  processes  and  is  a  key  to  the  successful  deployment  of  a 
solution  in  the  federal  acquisition  system. 

The  design  phase  is  split  into  two  major  functions.  The  first  is  the  actual  design  to 
the  accepted  solution,  and  the  second  is  the  development  of  the  operational  and  policy 
interfaces.  These  are  both  key  and  should  be  done  as  close  to  each  other  as  possible. 
These  are  within  the  same  phase  because  these  functions  are  not  only  closely  related  but 
are  dependent  on  each  other.  A  solution  should  be  designed  to  facilitate  the 
implementation  into  the  daily  activities  and  a  part  of  the  regular  operations  of  the  location 
under  consideration.  The  solution  must  not  only  provide  the  desired  security  capabilities 
but  be  used  to  be  effective. 

4.  Implementation 

The  implementation  phase  is  next.  This  includes  the  actual  implementing  the 
solution  and  validation  the  operational  and  policy  interfaces  between  the  end  users  and 
the  solution.  The  validation  of  the  proposed  solution  is  not  part  of  the  commercial  model 
but  key  in  the  larger  DoD/DHS  acquisition  framework.  The  validation  of  the  successful 
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application  of  the  operational  and  policy  interfaces  developed  in  the  last  phase  is  the  next 
logical  progression  in  the  process.  This  does  not  define  a  solution  is  a  success — just  that 
it  is  being  used  within  the  daily  process. 

Implementation  involves  the  actual  vendor  selection,  purchase  and  installation  of 
the  proposed  solution  developed  earlier  in  the  process.  This  will  also  include  the 
application  of  the  process  and  activities  that  have  been  developed  into  the  regular 
activities  of  the  end  users  to  ensure  the  solution  is  used.  A  proposed  solution  and  design 
may  change  when  actual  products  and  vendors  are  selected  and  as  the  solution  is  being 
installed.  This  is  a  result  of  conditions  that  may  have  not  have  been  known  prior  to  this 
phase  of  the  process.  These  changes  will  happen  if  only  on  a  small  scale  with  little  to  no 
impact  on  the  proposed  solution  but  should  be  tracked  to  ensure  that  any  impact  they 
have  is  mitigated  prior  to  the  solution  being  accepted.  The  installation  of  a  technical 
solution  by  electricians,  low  voltage  technicians  and  possibly  other  construction  trades  is 
a  key  component  in  the  long-term  viability  of  the  proposed  solution  and  should  not  be 
done  with  little  to  no  supervision  and  third  party  verification.  Small  changes  made  by 
these  professionals  in  the  installation  phase  can  have  a  drastic  impact  on  the  operational 
efficacy  of  the  solution  that  may  not  be  visible  to  the  installers. 

5.  Testing 

The  last  phase  commonly  used  in  the  development  of  an  ESS  is  testing  the  system 
against  the  design  to  ensure  the  system  was  completely  installed  and  any  changes  from 
the  design  are  clearly  identified.  This  is  the  second  to  the  last  phase  of  the  RADITC 
process.  This  is  testing  against  the  initial  requirements  and  not  against  the  design  or 
implementation  of  the  design  into  the  daily  activities.  Testing  against  meeting  the  initial 
requirements  is  the  acceptance  component  within  the  federal  acquisition  system  and  is  the 
final  step  prior  to  commissioning  the  solution.  The  testing  against  the  actual  requirements 
is  the  final  effort  that  a  solution  is  provided  that  meets  the  needs  and  is  actually  used  on  a 
regular  basis.  Typically  this  can  be  accomplished  with  a  checklist  of  all  the  initial 
requirements  and  at  least  two  signatures  of  individuals  that  have  first-hand  knowledge  the 
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needs  have  been  met.  Having  a  minimum  of  two  individuals  in  the  acceptance  process 
can  provide  the  checks  and  balances  needed  to  ensure  nothing  was  missed. 

6.  Commissioning 

That  last  step  of  commissioning  after  testing  is  how  the  alternative  process  ends. 
This  is  the  final  step  that  includes  finalizing  all  of  the  ownership  documentation,  ensuring 
all  the  invoices  have  been  paid,  and  ensuring  the  ongoing  operations  can  be  supported 
with  all  of  the  final  deliveries  of  the  process.  This  includes  a  survey  on  the  efficacy  of  the 
process  itself,  along  with  the  different  component  supplies  within  the  process.  As  the 
final  step,  this  will  include  all  of  the  local  closeout  contract  paperwork  and  will  normally 
identify  the  start  date  of  the  warranty,  maintenance  and  operations  phase  of  the  security 
solution. 

D.  COMPARISON  TO  DESIRED  CHARACTERISTICS 

1.  Simple 

The  RADITC  Process  could  be  used  by  anyone  who  has  basic  management  skills 
but  will  require  a  detailed  support  package  for  each  step  that  includes  all  of  the  details  to 
help  with  the  development  of  artifacts  for  each  step  or  certified  security  experts  to  help  at 
certain  times.  All  of  the  steps  can  be  modified  for  each  specific  problem  set  or  issues,  but 
the  steps  themselves,  and  the  order  they  fall  in  are  required  to  make  the  use  of  this 
method  a  success. 

The  alternative  analysis  activity  can  be  a  detailed  engineering  approach  or 
something  as  simple  as  a  basic  list  of  all  the  viable  solution  with  the  pros  and  cons 
associated  with  them  to  resolve  an  issue  within  the  current  environment.  How  detailed  or 
the  fonnat  of  this  effort  is  not  as  important  as  being  able  to  identify  technical  and 
nontechnical  solutions  for  each  requirement,  along  with  the  relative  cost  as  an 
implementation  and  operation  for  each.  This  should  provide  all  of  the  stakeholders 
involved  enough  information  to  judge  what  alternative  solution  would  fit  best  within  the 
way  they  operate  without  requiring  a  full  design  and  detailed  cost  estimate  for  each 
proposed  solution.  Solutions  should  not  be  biased  to  a  particular  technology  or  distinctive 
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attributes  of  a  specific  vendor.  Every  problem  has  at  least  two  viable  solutions  to  choose 
from,  if  they  are  looked  at  from  an  objective  point  of  view. 

A  detailed  design  is  the  next  step  after  the  selections  of  the  proposed  solutions  are 
determined.  The  design  should  take  into  consideration  all  the  interfaces,  needs  and 
constraints  based  on  the  location  in  consideration  that  was  discovered  in  the  requirements 
generation  process.  The  design  should  also  include  the  adaptation  of  any  regulatory 
information  required  and  include  life  safety  as  a  primary  consideration.  If  required, 
certified  personnel  to  include  a  registered  engineer  should  endorse  the  design  when  any 
construction  activities  are  required.  Stakeholder  approval  is  the  final  step  in  the  design 
process. 

The  implementation  step  is  straightforward  and  should  include  the  operation  and 
user  manuals,  along  with  user  training  to  ensure  the  system  is  fully  integrated  into  the 
operation  of  the  target  location. 

The  next  major  activity  is  a  key  component  of  the  entire  process.  Testing  of  the 
system  should  be  completed  to  ensure  the  original  requirements  have  been  satisfied.  A 
common  practice  is  to  test  against  the  design  to  see  if  the  design  product  is  installed 
properly.  This  requires  the  assumption  that  the  design  fully  satisfies  the  original 
requirements  and  any  modification  and  changes  made  in  the  implementation  had  no 
impact  on  solving  the  original  security  concern. 

The  alternative  process  facilitates  the  capture  of  the  end-users  requirements.  This 
ensures  any  proposed  solution  is  integrated  into  the  current  operations.  Testing  against 
the  end  users  needs  is  a  separate  step  within  the  new  process  and  the  solution  is  not  tested 
against  its  own  design  as  completed.  As  in  the  commercial  methodology,  there  is  no 
requirement  to  be  certified  or  a  trained  subject  matter  expert  to  use  the  process,  but  the 
more  anyone  uses  any  process  or  methodology,  the  easier  it  is  to  implement.  There  are  no 
references  to  a  specific  location  or  technology. 

The  data  points  are  connected  and  simple  to  understand  with  a  clear  meaning  or 
task.  Every  step  is  clear  and  easy  to  understand.  There  is  no  ambiguity  on  the  order  and 
inputs  of  each  step  and  there  is  a  clear  path  between  each  step.  The  new  process  is  easy  to 
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use.  The  process  is  not  tied  to  or  makes  any  reference  to  a  specific  technology  or  solution 
type.  This  meets  all  of  the  requirements  for  the  simple  characteristic. 

2.  Repeatable 

For  a  process  to  be  repeatable,  it  must  be  technology,  solution  and  location 
agnostic.  This  has  no  steps  in  the  process  that  requires  a  specific  solution.  Location 
considerations  or  location  specific  risk  activities  are  not  a  component  of  this  process.  The 
analysis  of  alternatives  activity  clearly  provides  for  the  identification  of  several 
alternative  solutions.  An  emphasis  should  always  be  on  lower  cost  operational  solutions 
prior  to  any  implementation  of  any  technical  solution.  A  technical  solution  should  always 
be  the  consideration  of  last  resort.  The  alternative  process  is  repeatable  because  it  is  both 
technology  and  location  agnostic. 

3.  Effective 

An  effective  solution  is  one  that  creates  a  good  set  of  end  user  requirements  and 
more  important  test  the  solution  against  those  requirements.  A  common  practice  in  the 
security  industry  has  an  expert  detennining  solutions  based  on  individual  experience  or  a 
limited  tool.  The  solution  is  then  tested  to  ensure  it  meets  the  design  requirements  of  that 
expert.  Two  key  components  of  the  DoD  life  cycle  acquisition  model  are  the  alternative 
of  analysis  process  and  testing  against  the  initial  end  user  requirements.  The  last  of  the 
major  activities  in  the  new  method  will  ensure  the  proposed  solution  will  meet  the  user’s 
needs.  The  first  major  activity  in  the  alternative  solution  is  the  development  of  end  user 
requirements. 

In  determining  if  the  alternative  solution  proposed  is  useful,  it  must  answer  yes  to 
the  following  three  questions: 

1 .  Does  it  clearly  define  requirements  by  supporting  the  identification  of  the 
end  user  needs? 

2.  Can  it  facilitate  the  integration  of  daily  activities  to  ensure  a  solution  will 
be  utilized? 

3.  Will  it  test  the  solution  directly  against  the  identified  needs? 
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The  alternative  solution  developed  in  this  paper  will  support  the  identification  of 
the  end  users  needs  and  test  against  those  needs.  Another  practice  not  commonly  found 
within  today’s  modem  application  of  electronic  security  systems  revolves  around  the 
solutions  integration  within  the  daily  activities  of  its  end  users. 

Too  many  times  a  computer,  monitor,  keypad  or  some  other  human  interface  in 
placed  in  an  office  or  on  the  wall  with  no  integration  of  that  electronic  security  solution 
into  any  regular  activity.  This  electronic  system,  along  with  any  other  item  not  regularly 
used,  will  go  unattended  and  in  time  may  be  turned  off,  if  not  just  ignored  completely. 
This  renders  all  of  the  cost  and  effort  in  designing  and  implementing  a  security  solution  a 
failure. 

Two  subprocess  steps  are  found  in  both  the  implementation  and  design  phases  of 
the  new  alternative  solution.  The  design  phase  has  subcomponents  titled  design  system 
and  develops  operations  and  policy  interfaces.  These  are  based  off  of  the  large  federal  life 
cycle  model  and  provide  the  framework  for  the  integration  into  the  regular  operations 
prior  to  the  implementation  phase.  The  design  system  subcomponent  is  self-explanatory. 
Once  a  solution  is  clearly  defined  and  designed,  the  operational  policies  for  the  use  of  the 
system  and  how  they  interface  with  the  solution  should  be  developed  prior  to  the 
installation  takes  place.  The  identification  of  issues  relating  to  the  existing  or  proposed 
policies  should  be  considered  prior  to  this  installation  in  case  this  activity  requires  a 
modification  in  design.  Too  many  times  a  solution  is  developed  and  installed  without  the 
consideration  of  training,  policies  and  local  laws  and  regulations  leaving  the  system 
ineffective,  if  not  useable  by  the  end  user  community. 

The  implementation  phase  includes  the  subprocess  of  installation  and  implements 
the  design  and  verifies  integration  of  the  solution  within  the  daily  operations.  The 
alternative  process  can  be  effective  solution. 
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V.  CONCLUSION 


If  I  had  an  hour  to  solve  a  problem  and  my  life  depended  on  the  solution,  I 
would  spend  the  first  55  minutes  determining  the  proper  question  to  ask, 
for  once  I  know  the  proper  question,  I  could  solve  the  problem  in  than  five 
minutes.  -Albert  Einstein 

A.  SUMMARY 

The  majority  of  the  processes  for  the  development  and  validation  from 
requirements  to  testing  of  electronic  security  systems  are  not  effective  or  easy  to  use. 
This  assessment  made  it  clear  that  the  commercial  option  is  a  viable  solution  with  other 
considerations  added,  but  the  best  solution  would  be  the  new  alternative  process 
developed  here.  Current  electronic  security  practices  start  with  a  site  survey,  and  then  go 
directly  into  equipment  selection  and  system  design.  This  does  not  provide  for  clearly 
defined  end-user  requirements  or  testing  a  proposed  solution  against  it. 

The  literature  reviewed  associated  with  electronic  security  systems  generally  did 
not  agree  that  specifications  are  made  up  of  functional  and  nonfunctional  requirements. 
They  usually  provided  a  step  that  included  some  set  of  questions  or  surveys  that  are 
suppose  to  lead  into  the  development  of  a  requirement.  However,  there  is  no  clear 
consensus  on  what  are  the  end  users’  needs  at  each  application,  how  to  capture  them  or 
even  consider  them  as  part  of  a  process  to  design  a  security  system.  A  majority  of  the 
processes  currently  found  in  the  literature  are  highly  dependent  on  the  skill  of  the 
practitioner  to  determine  solutions  with  little  to  no  empirical  data  inputs.  None  of  the 
process  found  currently  in  use  have  a  step  that  tested  or  validated  that  the  system  met  the 
initial  requirements,  with  no  definition  of  what  a  requirement  should  look  like  or  the  type 
of  data  it  should  contain.  The  implementation  of  this  new  alternative  process  will  enable 
those  involved  in  all  phases  of  a  system  implementation  to  have  a  clear  and  direct 
understanding  of  the  actual  needs.  This  will  improve  the  overall  physical  security 
solutions  developed  and  used  by  the  homeland  security  community. 

Theories  and  concepts  from  other  applications  or  problem  solving  techniques  can 
make  an  important  contribution  to  the  process  of  developing  descriptive  end-user 
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requirements.  The  identification  and  addition  of  that  process  to  the  current  best  practices 
can  enable  those  involved  in  all  phases  of  a  system  implementation  to  have  a  clear  and 
direct  understanding  of  the  actual  needs  more  effectively.  This  will  improve  the  overall 
physical  security  solutions  developed  and  used  by  the  homeland  security  community. 
Requirements  define  the  problem  and  technical  specifications  define  the  solution  to  the 
problem  (Cellucci,  2008,  p.  8).  Technology  is  not  the  only  solution  and  should  never 
stand-alone.  Even  when  technology,  employees  and  security  staff  cooperates,  security 
can  be  weakened  without  policy  and  procedures  supporting  the  security  measures 
(Gregory,  1994,  p.  10). 

B.  ADDITIONAL  CONSIDERATIONS 

In  2006,  a  terrorist  plot  was  foiled  planning  to  destroy  up  to  ten  commercial 
aircraft  traveling  from  the  United  Kingdom  to  North  America.  The  terrorist  planned  to 
use  liquid  explosives  for  this  event  and  this  resulted  in  a  ban  on  all  liquids  over  a  specific 
size  on  flights  within  the  United  States.  According  to  Kip  Hawley  (2012),  The 
Transportation  Security  Administration  bans  liquids  as  a  policy  solution  instead  of  a 
technology  solution  because  it  could  be  implemented  within  a  day,  cost  significantly  less 
and  functions  as  good,  if  not  better,  than  any  current  technology  available.  This  is  a  clear 
example  that  technology  is  not  the  only  solution  for  security  related  issues. 

1.  DOTMLPF 

The  Department  of  Defense  (DoD)  has  adopted  the  Doctrine,  Organizations 
Training,  Materiel,  Leadership  and  Education,  Personnel,  and  Facilities  (DOTMLPF) 
problem-solving  construct  (U.S.  Anny,  2005,  p.  56). 
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Figure  6.  DOTMLF  (From  FM1  p.  57) 


This  is  used  when  the  DoD  is  faced  with  a  need  that  it  has  not  encountered  before 
and  requires  a  solution.  In  this  construct,  the  first  step  is  Doctrine.  In  the  basic  form,  this 
is  consider  the  way  things  get  done  on  a  regular  basis.  The  first  look  at  an  alternative 
solution  is  based  on  answering  the  question  can  we  change  the  way  we  do  business  to 
solve  the  problem?  The  next  consideration  is  organization  and  then  training.  Only  after 
these  considerations  are  made  does  the  department  consider  a  material  solution.  This  is  an 
important  fact  since  a  material  solution  is  usually  the  first  choice  when  looking  at  most 
security  concerns.  Leadership  change  or  education,  staffing  and  building  are  final 
considerations  when  looking  to  solve  a  problem  by  the  Department  of  Defense. 

C.  FURTHER  STUDIES 

There  are  a  limited  number  of  scientific  studies  in  the  field  of  electronic  security. 
There  are  a  few  studies  on  the  effectiveness  of  video  surveillance  used  in  public  locations 
and  many  studies  on  the  ability  of  operators  that  actively  monitor  video  surveillance 
systems.  Many  federal  and  private  organizations  have  done  site-specific  test  to  see  if  an 
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electronic  security  system  functions  as  advertised  within  a  specific  location  or  scenario. 
This  research  found  no  formal  scientific  studies  of  Electronic  Security  Systems  providing 
an  additional  level  of  security.  The  RADITC  Process  is  a  new  process  to  develop  an 
effective  electronic  security  solution.  This  new  process  will  need  validation  with  real 
world  applications.  Additional  studies  are  needed  on  the  effectiveness  of  electronic 
security  systems  as  a  whole. 
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